ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group93a.txt/000083_icon-group-sender _Thu Mar 11 08:06:50 1993.msg

Internet Message Format | 1993-04-21 | 2KB

Received: by cheltenham.cs.arizona.edu; Thu, 11 Mar 1993 09:49:57 MST
Message-Id: <[e-mail]>
From: Ken Walker <[e-mail]>
Subject: Re: Icon :-> C | ADA translator wanted.
To: [e-mail]
Date: Thu, 11 Mar 93 8:06:50 PST
In-Reply-To: <[e-mail]>; from "Steve Holden" at Mar 11, 93 11:24 am
Mailer: Elm [revision: 66.25]
Status: R
Errors-To: [e-mail]

> From: Steve Holden <[e-mail]>
>
> Well, you might try "iconc -c", the Icon compiler with the
> final C-to-object step omitted.  The C it produces can only
> be described as somewhat obfuscated, though.

Yes, the code is really not meant for human consumption. The biggest
problem is automatic storage management. When an Icon varaible is
represented in C it must be accessable to the garbage collector.
This means that Icon variables are not represented as simple C
variables. In addition, Icon variables are untyped, so their C
representation must, in general, include run-time type information.
There are probably schemes for representing variables that would
result in better looking code than the compiler now produces and
making better use of information from type inferencing could also
help, but I think that producing human maintainable C code from
an Icon compiler would be quite difficult. It is worth noting that
automatic storage management causes problems for maintaining the
Icon run-time system and it is written with the goal of being
maintainable.

The other obvious problem is goal-directed evaluation. The compiler
goes through some contortions to translate the control flow mechanisms
of Icon into the more mundane mechanisms of C. Much of the time it
manages to produce fairly reasonable C code, but other times the
result looks rather odd.

Ken Walker, [e-mail]